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MULTIMEDIA COMMT TNTC AITONK nvpp p OW RR tumps 

CROSS-REFERENCE TO RELATED APPLICATIONS 
This application claims the benefit of U.S. Provisional Patent Application No 
60/234,016, filed September 20, 2000, which is incorporated herein by reference. 
5 FIELD OF THE INVENTION 

The present invention relates generally to data commumcations, and specifically to 
video and voice commumcations over electric power lines. 

BACKGROUND OF THE INVENTION 

Data communications using residential power lines are known in the art. An advantage 
) of using the lines is that only peripheral infrastructure needs to be added to the existing power 
knes m order to transmit and receive the data communications. With appropriate modems 
power Imes can be used to carry all the types of data traffic that are currently carried on local 
area networks (LANs), wide area networks (WANs) and internets, including real-time voice 
and video. Among the disadvantages of using power lines are high attenuation and the high 
level of interference on the lines, such as voltage spikes and Gaussian noise. These 
characteristics impose limitations on the available bandwidth and reliability of power line 
communications, which should be taken into account in the data services that are offered over 
power line networks. 

lb paokc. network* such aa the Internet, the Real-time Transport Protocol (RTP) ls 
commonly uaed to carry t^-ttae multimedia traffic, ^ myUn ^ mi<x ^ fa 
described by Shulzrinne e. al, in "RTP: A Ttanspor, Protocol , or Real-Time AppHcauone •• 
pubashed by the Network Working Group of the toteme. Engineering Teak Force (IETF) aa 
Request for Comment (RFC) (889 (1996), which ia incorporate* herein by reference RFC 
1889 specifies a forma, for RTP packed ma, includea a 12-byte RTP header and a 20-by.e 
payload, which are earned togeflter aa the payload of a User Datagram rnMIUmmt 
Protoco, (UDP/n») data packet The RTP head, include, a se„uencd numb, and time stamp 
whteb mcease by atepa tan one packet to me next in a RTP atream, along with a fixed' 
syacnrontsauon aource identifier (SSRC) field. Moat of the other fie.da and flags in the RTP 
^der change rare.y, if a. all, in me courae of a RTP session. RTP i. cnunecuoniess, hke 
TOP, m the sense mat RTP paoketa are atreamed continuoualy flom the aoume to the 
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destination, with no provision for verifying that the packets have reached their destination 
intact. 

The high overhead of RTP packets is a cause for concern when multimedia traffic is to 
be carried over low-bandwidth networks. The RTP, UDP and IP headers of a single packet 

5 add up to 44 bytes (compared to the 20-byte payload). The data link header (such as Ethernet) 
and additional signaling used for telephony applications, can easily add another 40 bytes, 
leaving only 20% of the channel bandwidth for the actual data. In response to this concern, 
Casner et al. suggest a method for RTP header compression on a link-by-link basis in IETF 
RFC 2508, entitled "Compressing TP/UDP/RTP Headers for Low-Speed Serial Links" (1999), 

10 which is incorporated herein by reference. This method takes advantage of the fact that most 
of the fields in the IP, UDP and RTP headers do not change at all during the RTP session, or 
change by an increment that is generally constant. On this basis, the IP/UDP/RTP header in 
most of the packets is compressed down to two bytes, or four bytes when UDP checksums are 
included. 

SUMMARY OF THE INVENTION 

It is an object of some aspects of the present invention to provide methods and 
apparatus for multimedia communications over power line communication (PLC) networks. 

It is a further object of some aspects of the present invention to provide methods and 
apparatus for efficient, reliable Voice over IP (VoIP) communications using PLC networks. 
20 In preferred embodiments of the present invention, a communications system 

comprises a plurality of data transceivers coupled to a network of power lines, preferably 
supplying mains voltage. Typically, the transceivers include a concentrator, which connects 
the power line network to a data communication network trunk, and power line modems in 
subscriber premises, which link subscriber equipment in the premises to the concentrator via 
25 the power lines. The power line modems preferably include both computer data ports, to 
which a user may connect a computer for serial or parallel data transfer, and telephone ports, to 
which the user may connect a conventional telephone handset. The concentrator is connected 
via the data communication trunk to a telephony server system, which preferably includes a 
gateway to a public switched telephone network (PSTN). Users can thus send and receive 
30 telephone calls over the power lines by communicating through the concentrator with the 
telephony server, using either their telephone handsets or telephony applications on their 
computers. 
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The transceivers monitor the traffic that they are conveying in order to detect streams 
of voice or video traffic, preferably by detecting RTP packets. When either the concentrator or 
one of the subscriber modems detects such a stream, it signals the transceiver at the other end 
of the link to establish a RTP connection for carrying the traffic. The connection is assigned a 
short (preferably one byte) connection identifier. The connection context, comprising the 
RTP, UDP and IP parameters that do not vary from packet to packet in the stream, is stored at 
both ends of the link, indexed by the connection identifier. Subsequently, for the duration of 
the connection, the sending transceiver removes the IP/UDP/RTP packet headers and, as long 
as the header parameters have not changed, substitutes a brief header containing the 
connection identifier and a sequence number for detecting lost packets. Periodically, the 
receiving transceiver returns an acknowledgment packet to the sender, indicating the sequence 
number of the last packet that was received intact, and informing the sender of any lost or 
corrupted packets. In this way, the narrow bandwidth of the PLC network is used efficiently, 
by reducing substantially the overhead of voice and video streams. At the same time, the 
reliability of voice and video communications is enhanced by adding an acknowledgment 
mechanism that is absent in the connectionless protocols usually used for real-time 
communications. 

There is therefore provided, in accordance with a preferred embodiment of the present 
invention, a method for communication, including: 

establishing a data link between first and second transceivers over an electric power 
line; 

receiving a sequence of data packets for transmission over the data link, the sequence 
belonging to a session of a connectionless real-time network protocol; 

responsive to a first packet in the sequence, establishing a reliable connection channel 
25 for the session over the data link between the first and second transceivers; and 

transmitting the packets in the sequence from the first to the second transceiver over 
the reliable connection channel. 

Typically, the packets include header information, and transmitting the packets 
includes compressing the header information in the packets transmitted using the channel from 
the first to the second transceiver. Preferably, establishing the reliable connection channel 
includes storing context information with respect to the session at the first and second 
transceivers, and compressing the header information includes compressing the header 
information using the stored context information. Further preferably, storing the context 
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information includes conveying the context information to the second transceiver along with a 
channel identifier in the first packet in the sequence, and compressing the header information 
includes inserting the channel identifier in the packets in the sequence following the first 
packet as a reference to the context information. Most preferably, the method includes 
5 reconstructing the compressed header information at the second transceiver using the stored 
context information referenced hy the channel identifier. Additionally or alternatively, 
compressing the header information includes detecting changes in the header information in 
successive packets in the sequence, and encoding the changes. 

Preferably, the method includes sending an acknowledgment from the second 
10 transceiver to the first transceiver responsive to at least some of the packets in the sequence 
transmitted by the first transceiver, thereby maintaini n g the reliable connection channel. 
Further preferably, estabhshing the reliable connection channel includes deteimining an 
acknowledgment interval that includes a given number of the packets, and sending the 
acknowledgment includes sending the acknowledgment every time the given number of 
1 5 packets has been received at the second transceiver. Most preferably, transmitting the packets 
includes adding an error detection code at the first transceiver to one of the packets in the 
acknowledgment interval, and sending the acknowledgment includes checking the error 
detection code at the second transceiver, and indicating a result of the checking in the positive 
or negative acknowledgment returned by the second transceiver. 
20 Additionally or alternatively, transmitting the packets includes adding a channel 

sequence number to each of the packets, and sending the acknowledgment includes sending an 
indication from the second transceiver to Ihe first transceiver when the channel sequence 
number of the packets received at the second transceiver deviates from a consecutive order. 

Further additionally or alternatively, estabhshing the reliable connection channel 
25 includes sending a request from the first transceiver to the second transceiver to allocate a 
resource for the channel, and sending the acknowledgment includes indicating to the first 
transceiver in a negative acknowledgment that the second transceiver does not have the 
resource available to open the channel. 

In a preferred embodiment, the first and second transceivers include a subscriber 
3 0 transceiver in a subscriber premises and a concentrator, and wherein the electric power line is a 
part of a mains voltage power line network to which the subscriber transceiver and the 
concentrator are connected. Typically, the subscriber transceiver is one of a plurality of such 
transceivers in multiple, respective subscriber premises connected to the power line network, 
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communication port, which is configured to exchange the voice data in the form of voice 
packets to and from a voice application on the personal computer. 

Preferably, the first transceiver includes one of a subscriber transceiver in a subscriber 
premises, and a concentrator, and the electric power line is a part of a mains voltage power line 
5 network to which the subscriber transceiver and the concentrator are connected. 

There is additionally provided, in accordance with a preferred embodiment of the 
present invention, communication apparatus, including: 

a subscriber transceiver, for deployment in a subscriber premises, the subscriber 
transceiver being adapted to be coupled to an electric power line belonging to a mains voltage 
1 0 power line network; and 

a concentrator, coupled to the power line netwoik so as to convey data between the 
subscriber transceiver and a packet communication trunk, the subscriber transceiver and the 
concentrator being configured to establish a data link therebetween over the electric power 
line, such that upon receiving a sequence of data packets for transmission over the data link, 
15 the sequence belonging to a session of a connectionless real-time network protocol, the 
subscriber transceiver and the concentrator are adapted, responsive to a first packet in the 
sequence, to establish a reliable connection channel for the session over the data link and to 
transmit the packets in the sequence from one to another over the reliable connection channel. 
The present invention will be more fully understood from the following detailed 
20 description of the preferred embodiments thereof; taken together with the drawings in which: 

BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 is a block diagram that schematically illustrates a system for power line 
communications (PLC), in accordance with a preferred embodiment of the present invention; 

Fig. 2 is a block diagram that schematically shows details of a power line data 
25 transceiver, in accordance with a preferred embodiment of the present invention; 

Fig. 3 is a block diagram that schematically shows communication protocols used to 
carry voice traffic in a PLC system, in accordance with a preferred embodiment of the present 
invention; 

Fig. 4 is a table that schematically illustrates a packet header used in real-time network 
30 communications; 

Fig. 5 is a flow chart that schematically illustrates a method for compressing packet 
headers in a PLC system, in accordance with a preferred embodiment of the present invention; 
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Fig. 6 la a flow ohart that schematically fflnstrates a method for decompressing 
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called party is available and that the call is authorized, and monitoring calls for billing 
purposes. A network management system (not shown) coupled to trunk 40 is responsible for 
allocating bandwidth to calls, depending on the load on PLC network 22. Preferably, the 
level of compression of the audio data carried on network 22 and trunk 40 is variable, under 
5 control of the network management system, in response to variations in the network load 

As an addition or alternative to gateway 42, telephone calls to and from transceivers 34 
may be handled through a virtual private branch exchange (PBX) 48, coupled to trunk 40. 
PBX 48 is preferably implemented as a special telephony application running on a 
general-purpose network server. In addition to interfacing with PSTN 44, PBX 48 acts as a 

10 switch in a private telephone network serving customers of the electrical utility company who 
use PLC network 22 for their telephone calls. PBX 48 routes local telephone calls between 
such customers through trunk 40 and the subscribers' local power lines 24, without using 
PSTN 44. This feature of the PBX allows the utility company to offer local telq>hone service 
at reduced rates, relative to the PSTN. Outgoing and incoming calls involving telephone 

15 subscribers outside the local PLC network are routed by PBX 48 to and from PSTN 44, in a 
manner similar to VoIP gateway 42. 

Voice telephony is thus carried over PLC network 22 in much the same way as other 
types of packet data, but with a few important differences. One difference is that the telephony 
packets are preferably assigned a high level of priority, relative to other types of traffic, so as 

20 to provide adequate quality of service (QoS) for real-time voice. In addition, the voice packet 
headers are compressed to conserve bandwidth on the PLC network, as described in detail 
hereinbelow. Other real-time multimedia traffic, such as real-time video, which is typically 
fed to PLC network 22 from the Internet and from entertainment networks, is preferably 
treated in a similar fashion to voice, with high priority and header compression. Therefore, 

25 although preferred embodiments are described herein primarily with reference to telephony 
applications, it will be understood that the principles of the present invention are similarly 
applicable to other types of real-time data traffic. 

Fig. 2 is a block diagram that schematically shows details of one of subscriber premises 
transceivers 34, in accordance with a preferred embodiment of the present invention. The 

30 design and operation of transceiver 34 are described in greater detail in PCT Patent 
Application PCT/IL01/00745, filed August 12, 2001, which is assigned to the assignee of the 
present patent application and whose disclosure is incorporated herein by reference. 
Transceiver 34 comprises a multi-function modem unit 50, which acts as an interface between 
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powr line 24 and low-voltage date inrcntnadon lines. Modules of unit 50 act as 
diversion circuity, ^.kg ^ ^ ^ ^ a ^ ^ ^ 

toh*hon, and converting the date to signals compauble with the power Hue, as well as 
Panning tte reveise operation . ^ modlUes ^ ^ ^ a ^ ^ 

52, and as level-setting circuitry for transmission of the data. 

34 * «-Pled to line 24 by an indusuy-stendard power socket 

56. A phys.cal rcterftoe (PHY) module 54 ante as a fuli-dup-e* convener betwe™ s^ial da* 
s^nds of a data fin* nni, 58 and power Into signals of pow ,in. 24. A logic module 60 
conunmncarcs with a cenfm, pressing uni, (CPU) module 62, which is used to opera* and 
control other modules comprised in tte nunscniver. to addition to acting as an overall 
ccntroller for transceiver 34. CPU 62 is utilized to convert da* received hyand transmitted to 
o*er module* of m. transceiver, as wen as to control routing communications befweon 
b™ ,4 and ota elemente of P!C netwo* 22. CPU 62 preferably openues using a 
voWe memo.y 66 such as a random access memory (RAM), containing a routing table 68 
»da nonvolatile memory 70. such as a flash memory. Memories 66 and 70 are coupled to 
CFU 62 by an internal bus line 64. 

CPU 62 communicates win, the otter modules of tmnrceiver 32 via logic module 60 

which acts as a multiplexer, transferring data to and from „,h«™-k_ • 

, . _ _ 6 ° mm subscriber equipment intafice 

modules 72. 78, 80, 82 and 86. whose function, are described below: 

• CODEC module 82, prefembly an indushy-standard CODEC, transmit, and 
rcemves standard telephone sigruds via an mdmfcy.^^ connector 84 to and from 
telephone 38. He CODEC converts me analog telephone signals te a suitebl. digitel 
fbm, sue* as the R323 fbnna. prcmulgated by tt. Internationa. Telecommunicadous 
Union (ITU), and vice vena, in a full -duplex manner. 

• ECP module 80 communicates witt penKmal computer 36 via an mdusuy.standard 
parallel port of the computer. 

• RS-232 module 86 provides industry-standard serial communication, via a 
connector 128. 

• Ethernet modiU. n fmUm pacle( ^ ^^.^ ^ 

^to»> such as fOBaseT. via a connector 74. Computer 36 may connect to module 
eitner directly via connector 74 or via a LAN 76. 
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• Alternatively or additionally, Universal Serial Bus (USB) module 78, which is 
preferably coupled directly to CPU 62, communicates with a USB tost via connector 
74. 

Fig. 3 is a block diagram that schematically illustrates protocols used in voice 

5 communications over PLC network 22, in accordance with a preferred embodiment of the 
present invention. The communications are shown, by way of example, as taking place 
between either personal computer 36 or telephone 38 and VoIP gateway 42, via subscriber 
PLC transceiver 34 and concentrator 32. The communications are generated at the subscriber 
end as a RTP packet stream, which is preferably produced by a suitable IP telephony 

10 application running on computer 36. Alternatively, the subscriber may use telephone 38 to 
generate audio and signaling. La this case, CODEC module 82 converts the telephone output 
to standard digital form, and data link unit 58 generates the RTP header data, as well as 
processing the RTP packets returned from the party at the other end of the telephone call. 

Thus, a subscriber-end protocol stack 100 shown in Fig. 3 comprises RTP, UDP and IP 

15 layers on the subscriber side, running over local media access control (MAC) and physical 
layer communications provide by the appropriate subscriber equipment interfaces, such as 
Ethernet interface module 72. When CPU 62 generates or detects an outgoing RTPAJDP/IP 
packet stream, it preferably establishes a point-to-point connection between transceiver 34 and 
concentrator 32 for the purpose of carrying the stream, and then compresses the packet headers 

20 in the RTP/UDP/IP session, as described in detail hereinbelow. Concentrator 32 preferably 
functions in like manner with respect to incoming packet streams from trunk 40. The RTP, 
UDP and IP layers are then carried on power line 24 between subscriber transceiver 34 and 
concentrator 32 by a special, compressed telephony layer, over the PLC MAC and physical 
layers generated by data link unit 58 and PHY module 54. The MAC layer protocol is 

25 described in detail in the above-mentioned PCT patent application. 

In a concentrator stack 102, running on concentrator 32, the compressed telephony 
layer for outgoing calls is decompressed to recover the original RTP, UDP and IP headers. 
Conversely, incoming RTPAJDP/IP headers are compressed for transmission to transceiver 34. 
The RTP/UDP/IP voice packets may also be carried over packet trunk 40 in compressed form, 

30 and decompressed at gateway 42 or at another point along the way. The MAC and PHY layers 
on the trunk side of concentrator 32 are typically those of a standard data link protocol used on 
the packet network to which trunk 40 belongs, preferably an Ethernet protocol. 
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stored in a pool in memory by both the transceiver and the concentrator (for example, in 
memory 66, Fig. 2). The context entries are preferably stored in the memory as a linked list, 
referenced by a hashing function based on a certain number of the least significant bits (LSB) 
of the RTP SSRC and the IP destination address for the respective sessions. Table I below 
shows a preferred structure for the memory pool context entries. 



TABLE I - SESSION CONTEXT PARAMETERS 



i^ategory 


Field 


Size 
(bits) 




f^rvnt^nrt TD CrY\ annftl minfiber^ 


8 


Counters 


MnmKor r\f rYYNTTP YT QTATF f AOC or "NACTFCl 

jNumuer oi v^v-jin ijda.i^oxaixi v/* a ~ ,js - ua 
pacKeis receiveu ^sce uesoripiiuu uciuw^ 


g 






16 


n 

Seq 


o e (juennai numoer ox coinprcsseu p<u*&£H 


4 


State 


Cnannel state (active, inactive, pending — see oeiowj 


A 
*T 


Time_tag 


Last update to this channel — channel is cleared after 
timeout occurs with no update 




RTP 


Pbit 


1 




Xbit 


1 
1 




cc 


*f 




Mbit 


1 
1 




"Dot/1 *"\Qf? fojnf* 

ir ayiodju. typo 


7 




Previous sequence number 


16 




Previous timestamp 


32 




SSRC 


32 




CSRC (pointer to list) 


16 


UDP 


Source port 


16 




Destination port 


16 


IP 


fflOL 


4 




Type of service 


8 




Previous ID 


16 




Flags 


3 
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15 





Fragments~~~" 


13 




Time to live ' — 


8 




Source address 


32 




Destination address ■ " 


32 




Options + padding " ' 


32 


Ethernet 


Source MAC address " 


48 




Destination MAC address ' 


48 


ACKs 




4 


rT 


Last CRC sent (on seq number) " 


16 




Debug state ~ " — — " 


1 


Next_entry 


Link to next entry or end of list J 


15 



20 
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conditions are not satisfied, a channel should not be opened, and the packet should instead be 
sent without compression at step 124. 

When a new channel is available, data link unit 58 creates the channel in its memory 
pool, and assigns it a context ID (CID), at a channel creation step 130. The memory pool now 
5 includes the full packet context, as specified in Table I above. To notify concentrator 32 that a 
new channel has been opened, unit 58 replaces the UDP length field in the UDP header (Fig. 
4) with a FULL — HEADER identifier field, at a header replacement step 132. The 
FUIX_HEADER identifier, shown below in Fig. 7A, includes the assigned CID and the 
starting link sequence number (Seq). The modified packet is then sent on to concentrator 32, 
10 at a new packet transmission step 134. Upon reading the packet header with the 
FULL_HEADER identifier, the concentrator opens the channel in its own memory pool, using 
the CID, Seq and context information in the packet header, and is now ready to receive 
compressed packets. 

When at step 126, data link unit 58 determines that the current RTP packet belongs to 

15 an existing session already opened in the memory pool, it updates the corresponding channel 
timejtag field, at a timer update step 136. It then checks the channel state (see Table J) to 
determine whether or not the channel is active, at an activity checking step 138. A channel is 
deemed inactive when the concentrator has signaled, using the acknowledgment mechanism 
described below, that it has received packets with errors or that packets have been lost on this 

20 channel. In such as case, the original packet is sent without header compression to 
concentrator 124. A channel may be deemed pending if, upon an attempt by data link unit 58 
to create the channel, concentrator 32 responds that its memory pool is full. Packets are 
likewise sent over pending channels without header compression. Such channels are 
ultimately erased from the memory pool of data link unit 58 by an aging mechanism if 

25 resources are not freed so that the pending channels can become active. 

When the RTP packet is found at step 138 to belong to an active channel, data link unit 
58 performs validity checks to ascertain that the channel is still valid, at a validity checking 
step 140. The packet header is then compressed, and the compressed packet is sent to 
concentrator 32, at a compressed transmission step 142. Details of steps 140 and 142 are 

30 described below with reference to Fig. 8. 

Fig. 6 is a flow chart that schematically illustrates processing of compressed packets 
received by concentrator 32 from transceiver 34, in accordance with a preferred embodiment 
of the present invention. (As in the case of the method of Fig. 5, this same method is carried 
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out by da* Hnk unit 58 of transceiver 34 when ft receives pack.* from to w _ r) 

*» ~ * - P— — «=P 150, concent 32 
**ks tire P»ket heade, By examining «„ packet ^ ^ ^ ^ 

drterrerne wheflKr „ packt< ^ to a toown rij> ieader to 

5 suppression determination sten 152 «•„„. « . P" 55 ' 00 We, at a 

r™*^ -.v ^ ffm ' ,toconoe,,ttator ^lysonds the p^ket onto n> 

trunk 40 without changes, at a packet pass-on step 154 excen. f„, «, 

,, j F -on step 154, except for the necessary changes to 

Bfhernetheaderll6(Fi g .4)thataremar^bystandardpretoco^ 

When concentrator 32 detects a RIP packet with a suppressed header type, ft next 

extsts m ,ts memory pool a . otame , js J 

ibr Are sendmg end re Tab.e I. One difference is Are, the memory poo! a, the recoivJZ 
~MAC^ofmepacke,son re .« ra3 4 ) JpLn«Z^ 

recmvmg end of the connexion can have only two stetes: active and inactive 

™ w" 16 ° f *" "** *~ ~* * *" »— at concenlretor 32 the 

step 158, As noted above, mis is Or. packet t>pe that transceiver 34 sends to inito. onenin! 
20 of anewchanneL If this is not the expected FULL HEADER hm , t 

sends a CONTHTfT o™ TO exp ea fULLHBADER type of packet, concentrator 32 
sends a CONTBXT_STATE packet back to transceiver 34, indicating tha, ft was unable to 
tire p.k«t a, a context reply step «. ^ CONraxT _ ^ ^ ^ m 

P * ^ - 4 by "» of compressed packed to signa, acknowledgment - A« Z 

negative acknowledgment -NACK „f«,. v. °w'eagment-ACK-or 

25 arise, for exampfe Then tiT wI ^ *—0 Ma situation may 
impie, when the transceiver reboots itself in the middle of rt,„ ^ • . 
sequence, or when the first FULL HBADPP u . • , transmission 

S St6p 16 °- ff too man y °f transceivers in subscriber premises 2fi 9R 

are busy making telephone calls over PLC network 22 the, ^ ' ' 

out of channels, m this case too th T concentrator may temporarily run 

in this case, too, the concentrator sends a CONTEXT_S TATE packet back to 
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transceiver 34, indicating that it is out of free channels, at a reply step 162. Despite the 
negative response, however, the concentrator is still able to reconstruct the original, standard 
RTP/UDP/IP header by recalculating the UDP length, at a length recalculation step 164, and 
reinserting the length into the UDP header of the packet in place of the FULLHEADER field 
5 that was substituted by transceiver 34. The concentrator then sends the reconstructed packet 
out over IP trunk 40. 

Returning to step 156, if concentrator 32 finds that the CID in the packet header exists 
in its own memory pool, it updates the time_tag in the corresponding channel context, at a 
timer updating step 170. It checks the source MAC address of the packet against the context, 

10 to ensure that the packet is valid, at a validity checking step 172. It also checks the sequence 
number (Seq) of the packet to ensure that it is exactly one greater than the preceding packet 
received on this channel. If so, concentrator 32 can proceed to decompress the packet and 
reconstruct the RTP/UDP/IP header, at a decompression step 174. Details of the 
decompression process are described hereinbelow. If a packet is missed, the channel becomes 

1 5 inactive, and the packet cannot be decompressed or sent 

In order to maintain synchronization between the sender and receiver of compressed 
packets, the receiver is required to acknowledge the compressed packets it has received, at an 
ACK requirement step 176. For this purpose, a time window, T, is defined at both the sending 
and receiving ends, such that every T compressed packets an acknowledgment protocol is 

20 carried out The sender preferably saves the sequence number and appends a cyclic 
redundancy code (CRC) value to the packet whose acknowledgment is required. The receiver 
recomputes the CRC and compares it to the appended value. If the CRC values match, the 
receiver returns an ACK packet (i.e., a CONTEXTJSTATE packet) with the sequence number 
to the sender, at an acknowledgment step 178. If there is a mismatch of the CRC values, the 

25 receiver returns a CONTEXTJSTATE NACK packet. In an optional debugging mode, the 
receiver may check the CRC of every packet, and send a NACK response to the sender for any 
packet in which the CRC check fails. When the sender receives the ACK response from the 
receiver, ^ checks the sequence number and CRC value against the values it has saved, and 
clears the values if they match. If the sender does not receive the proper ACK, it sends a 

30 FUIXJHEADER packet in order to refresh the channel context. 

When concentrator 32 determines at step 172 that a packet has been lost, it must send a 
NACK to transceiver 34, in the form of a CONTEXTJSTATE packet. The NACK packet 
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reports the sequence number of the last packet received and requests transmission of a 

FULL HEADER packet to update the channel context. 

Figs. 7A-7D are tables that schematically illustrates the types of packets sent between 

transceiver 34 and concentrator 32 in carrying out the compression and decompression 
■ protocols of Figs. 5 and 6. The packet types generally follow the definitions in the 

above-mentioned RFC 2508, with changes appropriate to the specific constraints and 
requirements of PLC network 22. Fig. 7A shows a FULLHEADER field 200 that is inserted 
in place of the length field in the UDP header (Fig. 4) of a foil RTP/UDP/IP packet header 
Field 200 includes a version number 202 (for example, "01"), context ID (CID) 204, and a 
current sequence number (Seq) 206. An optional «D» bit invokes the above-mentioned debug 
mode, in which a CRC is added by the sender to each of the compressed packets and is 
checked by the receiver. 

Fig. 7B shows a COMPRESSED.TJDP packet 210, which is sent by the transmitter 
when the P, X or PT field in the RTP header has changed. When such a change occurs 
additional information must be conveyed to the receiver in order to update the channel context' 
and this mformation is conveyed by the COMPRESSED_TJDP packet. The packet header 
includes CID 204 and Seq 206, as well as an <T' flag 212. This flag is set if the IP version 4 
(IPv4) ID has changed by an amount other than one from the preceding packet to this one. If 
«T» is set, packet 210 includes a AIP field 214 that gives the actual ID change. Preferably, the 
change in ID is encoded using a Huflman encoding scheme, as is known in the art, so that 
common values of the ID change (typically in the range 0:127) are encoded as a single byte 
while less common values take two or three bytes. A scheme of this sort is suggested in RFC 
2508. No further encoding of the IP or UDP header is required. (If it were a 
FULLHEADER packet would be sent.) The packet next includes UDP data 216 which 
comprises the Ml RTP header and payload, followed by an optional checksum 218 

Fig. 7C shows a COMPRESSED.RTP packet 220, which is sent when the changes in 
the RTP/UDP/IP header are minimal. Following CID 204, the packet includes compression 
flags 222, with the following meanings: 

• "M» indicates that the «M» bit in the RTP header has changed. 

• "S" indicates that the RTP sequence number has changed by an amount different 
from the usual sequence increment. In this case, a ARTP sequence field 224 contains 
the actual change in the sequence number, preferably using a Huffman encoding 
scheme as described above. 
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• *T" indicates the RTP timestamp has changed by an amount different from the 
usual time increment In this case, a ARTP timestamp field 226 contains the actual 
change in the timestamp, preferably using a Huffinan encoding scheme as described 
above. 

5 • "I" indicates that the IPv4 ID has changed by an amount different from one, with its 

actual change given by field 214. 

• When all of M, S, T and I are set, and a CC field 223 is not equal to zero, a CSRC 
list 228 is included in packet 220, with a length given by the value of CC. In this case, 
the values M=S=T=I=1 are artificial, to signal that the packet includes the CSRC list, 

10 and the roles of flags M, S, T and I are respectively assumed by flags M\ S', T and I\ 

If the "X" bit is set in the RTP header, the header extension is contained in a RTP header 
extension field 230. The remainder of the packet contains RTP data 232, followed by optional 
padding 234 (if the <ff P" bit is set) and checksum 218. 

Fig. 7D shows a CONTEXTJSTATE packet 240, used for the ACK and NACK 

15 functions described above. An <C F" bit 242 is set by the receiver to indicate that its memory 
pool is full, so that a new channel that the transmitter has asked to open must remain in the 
pending state. An "A" bit 244 is set to indicate a positive acknowledgment (ACK), and is 
reset for NACK. Seq field 206 indicates the sequence number of the last packet that the 
receiver was able to read on this channel. The use of the C ONTEXT_STATE packet in this 

20 manner (which differs from that proposed in RFC 2508), with a predefined window for 
positive ACK response by the receiver, turns the unidirectional, connectionless RTP/UDP 
packet stream into a full-duplex, connection-oriented protocol within PLC network 22, while 
at the same time saving substantial bandwidth. Both of these features are particularly 
important when working over power line 24, with its high noise level and low bandwidth. 

25 Fig. 8 is a flow chart that schematically illustrates the use of packet formats 200, 210 

and 220 in sending compressed RTP packets over PLC network 22, in accordance with a 

preferred embodiment of the present invention. The steps of the method shown in Fig. 8 

» 

correspond roughly to validity checking step 140 and compressed transmission step 142 in Fig. 
5, after transceiver 34 has ascertained that the RTP packet in question belongs to an active 
30 channel in its memory pool. 

The method of Fig. 8 is initiated when transceiver 32 receives a RTP packet to 
compress on a valid, active channel, at a packet reception step 250. The transceiver first 
checks fields that are supposed to remain constant over an entire RTP session: the IP source 
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ad*** and a. UDP ports . „ a feM checfcing ^ ^ ff ^ rf ^ 

have changed in the cmren. packet, relative to the channel context in the memory poo., the 
ennea. channel is emsed, a. an emsure step 254. A new channel may be created in its place 
with the new parameters. 

S Ne* me tnmsceiver checks whether any of the other IP panmreteis have changed, a, 

an IP checkmg step 256. These fields axe also g^erally consten, during a session, Witt, the 
excephon of the IP ID fie.d, which ia incremented fiom packet te packet If any of the 

FUIi.HEADBR packet a, a full transmission step 258. Ms packet refreshes me contents of 

the channel context, tat withont creating a new channel. 

If the packet passes stop 256 successfully, the tmnsceiver checks to detomrine whether 
any of the P.XorPT fields of me RT* header have change relative to me charme. context a, 
a RTP parameters checking step 260. As noted above, if any of these fields have changed, 
compressed UDP ^ 220 „ ^ „ . ^ ^ 

tnemment has changed, the packet will also include the appropriate AIPv4 ID field 214 

ff --° f ^RWfieldsh OT .cha J1 ged,m.han S ceivercbcckam.„merR TO h M der 
fields, as well as me IP ID field, in order ,„ encode any changes in me fields, at an RTP 
en^dmg step 264. aese changes induce changes in m. fields memselves, for the M and 
CSRC fidda, as well as changes in me increment of the sequence nmnber, umestomp and IP 
» nelda. Any changes are encode in me manner described above, and me contending 

TlZ^ZT ^ aC0OnUll8ly - " «• Most ofle rime! 

fields 21 , 224, 226 and 22g m emp* „ « ^ m ^ fcH 2M ^ ' 

can now be sent to the concentrator 32. 

In order to monitor degression processing activities, concentrator 32 preferably 
maintains the following counters: preieraoiy 

• Global counters - 

• Total RTP packets reconstructed. 

• Total synchronizing (FULL_HEADER) packets received. 

• Total semi-compressed packets received (COMPRESSED_UDP). 

• Total nUiy-compressed packets received (COMPRESSED.RTP). 

• T^^^nizmgpacketssentCCOmEXT.STATEwithFbitoff). 

• To ^reject P acketssent(CONTEXT^STATEwithFbiton). 

• Total active channels. 
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• Total inactive channels. 

• Number of available channels. 
• Per-channel counters — 

• Total compressed packets received. 

5 . Total synchronizing packets sent (CONTEXT_STATE with F bit off). 

Reconstruction of the compressed packets, at decompression step 174 (Fig. 6) is a 
mirror image process to that shown in Fig. 8. When the compressed packet is a 
COMPRESSED_UDP packet, concentrator 32 generates the decompressed RTP packet to 
send over trunk 40 using the RTP channel information in UDP data 216, along with the 
10 remaining context data for the channel that is stored in the memory pool. The concentrator 
increments the IP ID by 1 if 1=0, or by the number indicated in field 214 of the packet if 1=1. 

For a COMPRESSEDJRTP packet, if M=S=T=I=1, and CC is non-zero, the CC field 
in the channel context is updated with the value in field 223 of packet 220, and the CSRC list 
in the context is replaced with the contents of field 228 in the packet. This new information is 

15 used in all reconstructed packets, beginning with the current one. Depending on the values of 
M, S, T and I (or of M\ S', T and I\ if M=S=T=I=1), the rernaining variable fields of the 
RTP packet are reconstructed, using constant increments or the special increments given in 
fields 214, 224 and 226. Header extension 230 and padding 234 are optionally added to the 
packet, the UDP length is recalculated, and the packet is sent out on trunk 40 as a standard 

20 RTP/UDP/IP packet 

As noted above, although the processes of channel creation and of compression and 
decompression of RTP packets are described with respect to packets transmitted from 
subscriber equipment, via transceiver 34, to concentrator 32 over power line 24, similar 
methods are used to create channels and to compress and decompress packets received by 

25 concentrator 32 from packet trunk 40 for transmission over the power line to transceiver 34. 
Furthermore, although for the sake of clarity, these processes are illustrated with reference to a 
single connection in the very simple PLC network 22 shown in Fig. 1, it will be understood 
that the methods exemplified by the preferred embodiments described herein may equally be 
applied in more complex PLC network topologies, with multiple RTP sessions going on 

30 simultaneously. 

More generally speaking, while RTP/UDP/IP provides particularly fertile ground for 
creating connection-oriented sessions and performing header compression in a PLC network, 
the principles of the present invention may also be applied to other connectionless protocols, 
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particularly real-time protocols, that are used in the PLC network environment Furthermore, 
allhough preferred embodiments are described herein with specific reference to PLC networks,' 
the principles of the present invention may also be applied, mutatis mutandis, to encapsulation 
and compression of packets transmitted over wireline and wireless networks of other types, 
particularly networks that, like PLC networks, have high noise and errorrates. 

It will thus be appreciated that the preferred embodiments described above are cited by 
way of example, and that the present invention is not limited to what has been particularly 
shown and described hereinabove. Rather, the scope of the present invention includes both 
combinations and subcombinations of the various features described hereinabove, as well as 
variations and modifications thereof which would occur to persons skilled in the art upon 
reading the foregoing description and which are not disclosed in the prior art 
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CLAIMS 

1. A method for communication, comprising: 

establishing a data link between first and second transceivers over an electric power 

line; 

5 receiving a sequence of data packets for transmission over the data link, the sequence 

belonging to a session of a connectionless real-time network protocol; 

responsive to a first packet in the sequence, establishing a reliable connection channel 
for the session over the data link between the first and second transceivers; and 

transmitting the packets in the sequence from the first to the second transceiver over 
1 0 the reliable connection channel. 

2. A method according to claim 1, wherein the packets comprise header information, and 
wherein transmitting the packets comprises compressing the header information in the packets 
transmitted using the channel from the first to the second transceiver. 

3. A method according to claim 2, wherein establishing the reliable connection channel 
15 comprises storing context information with respect to the session at the first and second 

transceivers, and wherein compressing the header information comprises compressing the 
header information using the stored context information. 

4. A method according to claim 3, wherein storing the context information comprises 
conveying the context information to the second transceiver along with a channel identifier in 

20 the first packet in the sequence, and wherein compressing the header information comprises 
inserting the channel identifier in the packets in the sequence following the first packet as a 
reference to the context information. 

5. A method according to claim 4, and comprising reconstructing the compressed header 
information at the second transceiver using the stored context information referenced by the 

25 channel identifier. 

6. A method according to claim 2, wherein compressing the header information comprises 
detecting changes in the header information in successive packets in the sequence, and 
encoding the changes. 

7. A method according to claim 1, and comprising sending an acknowledgment from the 
30 second transceiver to the first transceiver responsive to at least some of the packets in the 
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sequence transmitted by the first transceiver, thereby maintaining the reliable connection 
channel 

8. A method according to claim 7, wherein estabhshing the reliable connection channel 
comprises determining an acknowledgment interval that comprises a given number of the 

5 packets, and wherein sending the acknowledgment comprises sending the acknowledgment 
every time the given number of packets has been received at the second transceiver. 

9. A method according to claim 8, wherein transmitting the packets comprises adding an 
enor detection code at the fixst transceiver to one of the packets in the acknowledgment 
interval, and wherein sending the acknowledgment comprises choking me enor detection 

1 0 code at the second transceiver, and indicating a result of the checking in the acknowledgment 

10. A method according to claim 7, wherein transmitting the packets comprises adding a 
channel sequence number to each of the packets, and wherein sending the acknowledgment 
comprises sending an indication from the second transceiver to the firat transceiver when the 
channel sequence number of the packets received at the second transceiver deviates from a 

1 5 consecutive order. 

II. A method according to claim 7, wherein establishing the reliable common channel 
comprises sending a request from to firs. Imnsoetver to the second tranter to allocate a 
resource tor to channel, and wherein sending the acknowledgment comprises indicating to the 
firs, tamsceiver whether or not the second hansceiver has the resource available to open the 
20 channel. 

12. A method according to any of dahna 1-11, wherein the tat and second transceivers 
compns. a snbscriher transceiver in a subscriber premises and a concentrator, and wherein the 
electee power line is a part of a mains voltage power line network ,„ which to subscriber 
transceiver and the concentrator are connected 

25 13. A method according to claim 12, wherein the subscriber transceiver is one of a plurality 
ofsuc .transceivers in multiple, respective subscriber premises connected to to power line 
n*wo*. and wherein to concentrator is coupled to bnk to ptarafity of the tranaceivera to a 
packet communication trunk. 

30 1 Am ^~ gtoC,atal3 - Whereto -^^-l--eoftodatepaclcete 
compnses reeetvmg a reai-time date flow to be conveyed befcveen to subscriber premises and 
a network server via the packet communication trunk. 
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15. A method according to claim 14, wherein receiving the real-time data flow comprises 
receiving telephony data, and wherein the network server comprises a telephony gateway, 
which is coupled to a puhlic switched telephone network (PSTN). 

16. A method according to claim 15, wherein receiving the telephony data comprises 
5 receiving data associated with a telephone call placed from one of the multiple subscriber 

premises connected to the power line network to another of the multiple subscriber premises, 
and wherein the telephony gateway is further configured to serve as a virtual exchange, so as to 
convey the telephony data from the one of the subscriber premises to the other without sending 
the data through the PSTN. 
10 17. A method according to any of claims 1-1 1, wherein receiving the sequence of the data 
packets comprises receiving real-time multimedia data- 

18. A method according to claim 17, wherein receiving the multimedia data comprises 
receiving video data. 

19. A method according to claim 17, wherein receiving the multimedia data comprises 
1 5 receiving voice data. 

20. A method according to claim 19, wherein receiving the voice data comprises coupling 
a telephone handset to one of the transceivers, and conveying the voice data as an analog audio 
signal between the one of the transceivers and the telephone handset. 

21. A method according to claim 19, wherein receiving the voice data comprises coupling 
20 a personal computer to one of the transceivers, and conveying the data packets between the one 

of the transceivers and a voice application on the personal computer. 

22. A method according to any of claims 1-11, wherein receiving the sequence of the data 
packets comprises receiving the packets in accordance with a Real-time Transfer Protocol 
(RTP). 

25 23. Communication apparatus, comprising a first data transceiver, which is configured to 
establish a data linlc with a second data transceiver over an electric power line, such that upon 
receiving a sequence of data packets for transmission over the data link, the sequence 
belonging to a session of a connectionless real-time network protocol, the first data transceiver 
is adapted, responsive to a first packet in the sequence, to establish a reliable connection 

30 channel for the session over the data link with the second transceiver and to transmit the 

packets in the sequence to the second transceiver over the reliable connection channel. 
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24. Apparatus according to claim 23, wherein the packets comprise header information, 
and wherein the first data transceiver is adapted to compress the header information in the. 
packets for transmission using the channel. 

25. Apparatus according to claim 24, wherein to establish the reliable connection channel 
context information with respect to the session is stored at the first and second transceivers, 
and wherein the first data transceiver is adapted to compress the header information using the 
stored context information. 

26. Apparatus according to claim 25, wherein the first transceiver is adapted to convey the 
context information to the second transceiver along with a channel identifier in the first packet 
in the sequence, and to insert the channel identifier in the packets in the sequence following 
the first packet as a reference to the context information. 

27. Apparatus according to claim 26, wherein the compressed header information is 
reconstructed at the second transceiver using the stored context information referenced by the 
channel identifier. 

15 28. Apparatus according to claim 24, wherein the first transceiver is adapted to compress 
the header information by detecting changes in the header information in successive packets in 
the sequence, and encoding the changes. 

29. Apparatus according to claim 23, wherein the first transceiver is adapted, after 
estabhshing the reliable connection channel, to receive an acknowledgment from the second 
transceiver responsive to at least some of the packets in the sequence transmitted by the first 
transceiver, thereby maintaining the reliable connection channel. 

30. Apparatus according to claim 29, wherein the first transceiver is adapted to instruct the 
second transceiver to send the acknowledgment every time a given number of packets making 
up a Predetermined acknowledgment interval has been received at the second transceiver. 

31. Apparatus according to claim 30, wherein the first transceiver is adapted to add an 
error detection code to one of the packets in the acknowledgment interval, and to receive from 
the second transceiver in the acknowledgment a result of checking the error detection code. 

32. Apparatus according to claim 29, wherein the first transceiver is adapted to add a 
channel sequence number to each of the packets, and to receive an indication in the 
acknowledgment from the second transceiver when the channel sequence number of the 
packets received at the second transceiver deviates from a consecutive order 
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33. Apparatus according to claim 29, wherein the first transceiver is adapted to send a 
request to the second transceiver to allocate a resource for the reliable connection channel, and 
to receive the acknowledgment indicating whether or not the second transceiver has the 
resource available to open the channel. 
5 34. Apparatus according to any of claims 23-33 wherein the sequence of the data packets 
comprises real-time multimedia data. 

35. Apparatus according to claim 34, wherein the multimedia data comprise video data. 

36. Apparatus according to claim 34, wherein the multimedia data comprise voice data. 

37. Apparatus according to claim 36, wherein the first transceiver comprises a telephone 
10 adapter, which is configured to exchange the voice data in the form of analog audio signals to 

and from a telephone handset. 

38. Apparatus according to claim 36, wherein the first transceiver comprises a computer 
communication port, which is configured to exchange the voice data in the form of voice 
packets to and from a voice application on the personal computer. 

15 39. Apparatus according to any of claims 23-33, wherein the connectionless real-time 
protocol comprises a Real-time Transfer Protocol (RTP). 

40. Apparatus according to any of claims 23-33, wherein the first transceiver comprises 
one of a subscriber transceiver in a subscriber premises, and a concentrator, and wherein the 
electric power line is a part of a mains voltage power line network to which the subscriber 

20 transceiver and the concentrator are connected. 

41. Communication apparatus, comprising: 

a subscriber transceiver, for deployment in a subscriber premises, the subscriber 
transceiver being adapted to be coupled to an electric power line belonging to a mains voltage 
power line network; and 

25 a concentrator, coupled to the power line network so as to convey data between the 

subscriber transceiver and a packet communication trunk, the subscriber transceiver and the 
concentrator being configured to establish a data link therebetween over the electric power 
line, such that upon receiving a sequence of data packets for transmission over the data link, 
the sequence belonging to a session of a connectionless real-time network protocol, the 

30 subscriber transceiver and the concentrator are adapted, responsive to a first packet in the 
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sequence, to establish a reliable connection channel for the session over the data link and to 
transmit the packets in the sequence from one to another over the reliable connection channel. 

42. Apparatus according to claim 41, wherein the sequence of the data packets comprises a 
real-time data flow to be conveyed between the subscriber premises and a network server via 
the packet communication trunk. 

43. Apparatus according to claim 42, wherein the real-time data flow comprises telephony 
data, and wherein the network server comprises a telephony gateway, which is coupled to a 
public switched telephone network (PSTN). 

44. Apparatus according to any of claims 41-43, wherein the subscriber transceiver is one 
of a plurality of such transceivers in multiple, respective subscriber premises connected to the 
power line network, and wherein the concentrator is coupled to link all of the plurality of the 
transceivers to the packet communication trunk, 

45. Apparatus according to claim 44, wherein the sequence of the data packets comprises 
telephony data associated with a telephone call placed from one of the multiple subscriber 
premises connected to the power line network to another of the multiple subscriber premises, 
and comprising a telephony gateway, coupled to the packet communication trunk, which is' 
configured to serve as a virtual exchange, so as to convey the telephony data from the one of 
the subscriber premises to the other without sending the data through a public switched 
telephone network (PSTN). 

46. Apparatus according to claim 45, wherein when the telephony gateway is further 
coupled to the PSTN so as to convey telephone communications between the PSTN and the 
multiple subscriber premises. 
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